3 research outputs found

    Defence against Denial of Service (DoS) attacks using Identifier-Locator Network Protocol (ILNP) and Domain Name System (DNS)

    Get PDF
    This research considered a novel approach to network security by combining a new networking architecture based on the Identifier-Locator Network Protocol (ILNP) and the existing Domain Name System (DNS). Specifically, the investigations considered the mitigation of network-level and transport-level based Denial of Service (DoS) attacks. The solutions presented for DoS are applicable to secure servers that are visible externally from an enterprise network. DoS was chosen as an area of concern because in recent years DoS has become the most common and hard to defend against attacks. The novelty of this approach was to consider the way the DNS and ILNP can work together, transparently to the application, within an enterprise scenario. This was achieved by the introduction of a new application-level access control function - the Capability Management System (CMS) - which applies configuration at the application level (DNS data) and network level (ILNP namespaces). CMS provides dynamic, ephemeral identity and location information to clients and servers, in order to effectively partition legitimate traffic from attack traffic. This was achieved without modifying existing network components such as switches and routers and making standard use of existing functions, such as access control lists, and DNS servers, all within a single trust domain that is under the control of the enterprise. The prime objectives of this research were: • to defend against DoS attacks with the use of naming and DNS within an enterprise scenario. • to increase the attacker’s effort in launching a successful DoS attack. • to reduce the visibility of vulnerabilities that can be discovered by an attacker by active probing approaches. • to practically demonstrate the effectiveness of ILNP and DNS working together to provide a solution for DoS mitigation. The solution methodology is based on the use of network and transport level capabilities, dynamic changes to DNS data, and a Moving Target Defence (MTD) paradigm. There are three solutions presented which use ILNP namespaces. These solutions are referred to as identifier-based, locator-based, and combined identifier-locator based solutions, respectively. ILNP-based node identity values were used to provide transport-level per-client server capabilities, thereby providing per-client isolation of traffic. ILNP locator values were used to allow a provision of network-level traffic separation for externally accessible enterprise services. Then, the identifier and locator solutions were combined, showing the possibility of protecting the services, with per-client traffic control and topological traffic path separation. All solutions were site-based solutions and did not require any modification in the core/external network, or the active cooperation of an ISP, therefore limiting the trust domain to the enterprise itself. Experiments were conducted to evaluate all the solutions on a test-bed consisting of off-the-shelf hardware, open-source software, an implementation of the CMS written in C, all running on Linux. The discussion includes considering the efficacy of the solutions, comparisons with existing methods, the performance of each solution, and critical analysis highlighting future improvements that could be made

    Cloud Computing for Telecom Systems

    No full text
    Context: Cloud computing is reshaping the service-delivery and business-models in Information and Communications Technology (ICT). The Information Technology (IT) sector has benefited from it in the previous 3-5 years. Despite the attraction of cloud computing, it is required to have an effective application migration strategy. Cloud computing with its diverse provisioning models makes it possible for telecom vendors and service providers to decide effective service and business models. Currently, cloud computing contains security, performance and dimensioning considerations for telecom companies. Objectives: This thesis assesses the trends and issues associated with the cloud, with telecommunications perspective, while leveraging the cloud to come to a decision on a suitable cloud environment for telecom grade applications. Analysis of maturity of public cloud (in terms of compatibility, consolidation, compliance and standardization) in general and Amazon cloud in particular, is part of the thesis objective. While doing so, deployment of a telecom-grade product in the Amazon cloud will be evaluated against the current on-premise deployment. We want to identify architectural difference between the two domains, and what issues are faced when a migration is planned. This evaluation between two systems, i.e. on-premise and the cloud will significantly contribute to the research and can be used when making business decisions. Methods: We conducted literature review, survey, and a case study, assessing the above mentioned objectives. Research papers from academia and industry were chosen for literature review; personnel, with experience in cloud computing, were chosen for the survey; and a telecom-grade platform was used to assess the migration issues on Amazon cloud in the case study. The Ericsson Composition Engine (ECE) was used to check what deployment issues it can have on Amazon cloud. Its on-premise Reference Deployment Architecture was compared with the cloud-based Reference Deployment Architecture. This case study served as a confirmation to results obtained in the literature review and survey. Results: In the literature review and survey, we found motivations, trends, current applications, and challenges of cloud computing for telecom. It was found from the case study that Amazon Web Services (AWS) lacks application and network centric attributes that are required in ECE deployment. We propose recommendations that can be integrated with ECE while deploying it in a public cloud. Conclusions: Companies are choosing cloud vendors that uniquely give ease of migration and control, based on application needs and compatibility. ECE cannot be directly migrated to AWS, unless we provide Amazon specific modifications in the architecture. The survey and literature review support a private and/or hybrid strategy for ECE, along with the inclusion of cloud networking into the ECE package
    corecore